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DETAILED ACTION 

1 . This action is in response to Applicant's submission filed 5/2/06, responding to the 
1 1/2/2005 Office action which detailed the rejection of claims 1-26. No claims have been 
amended, canceled, or added. Claims 1-26 remain pending in the application and have been 
fully considered by the examiner. 

2. Applicant has essentially argued that the rejections under U.S.C. 35 § 103(a) is improper. 
These arguments are not persuasive as set forth below. 

3 . THIS. ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1 .136(a) will be calculated from the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than SIX MONTHS from the mailing 
date of this final action. 

Response to Arguments 

4. On page 7 of the response filed 5/2/2006, Applicant essentially argues that the 
"specification of separate Applications, Data Models and Integration Components" in Figure 2 
shows that the data model is "obviously decoupled." However, this does not appear to be 
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obviously decoupled since Figure 2 merely displays the text "Data Models" grouped together 
along with "Applications", "Integration", and "Components". There does not appear to be any 
indication regarding the "Data Models" as being decoupled. 

Likewise, element 316 in Figure 3 merely shows that a data model is deployed. There is 
no indication that the data model is decoupled. Simply listing a data model separately from 
another component does not particularly show that it is decoupled. Further, the "update of data 
models as a separate step (412)" in Figure 4 also does not provide any particular indication of the 
decoupled nature of the data model. Applicant asserts that each step shown in Figure 4 was 
"drawn separately at least to show how they are decoupled from one another". However, review 
of page 16 lines 1-8 of the originally filed specification shows that the word "decoupled" only 
appears to be used tangentially in reference to the data model mentioned in step 412, and is not 
used at all in reference to the other steps in Figure 4. As such, it does not appear that Figure 4 
particularly shows the decoupled nature of the data model. 

Applicant continues on page 8 to describe the usage of rules shown in Figure 4 and the 
support for a decoupled data model allegedly shown in on pages 20 and 27 of the related 
provisional application. However, these arguments do not appear to further provide support for 
the objection to the drawings to show the decoupled mobile data model (claims 1, 1 1, 17, 22, and 
24), a mobile data model "operable to enable changes in data structure and data handling without 
requiring programmatic changes" (claim 11), the "changes to the mobile data model <that> 
effect changes in system data descriptions and rules governing data handling without requiring 
programmatic changes in applications included in an enterprise back-end device" (claim 17), 
and the "mobile data model decoupled from a particular client interface and enterprise data 
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source" (claim 24). Applicant's arguments are not persuasive. Accordingly, the objection to the 
drawings is maintained. 

5. On pages 9-11, Applicant addressed the rejection of claims 1 1-16 under 35 U.S.C. 1 12, 
1 st paragraph. 

On pages 9-10, Applicant essentially argues that support a "mobile data model . . . 
operable to enable changes in data structure and data handling without requiring programmatic 
changes in the enterprise back end" is found on page 16 lines 14-15 and page 17 lines 2-3. 
However, while these passages may state that the data model can be changed, it still does not 
address how the mobile data model is "operable" to enable change without requiring 
programmatic changes. To the contrary, the passage cited by Applicant suggests that a data 
model is changed when application requirements change. A change of application requirements 
implies programmatic change. The portion of the originally filed specification cited by 
Applicant still does not appear to describe how this is accomplished. Therefore, Applicants 
argument is not persuasive. 

Further on page 10, Applicant essentially argues that use of the term "portions" is used to 
show that certain clients or backend connections may be interested only in a portion of the data 
model, and that it "should be fairly obvious" that if someone changed those portions not 
deployed, then code wouldn't have to change as discussed on page 30 lines 7-8 of the originally 
filed specification. However, it is not clear exactly what code wouldn't have to change. The 
term "portion" suggests that a subset of the data model is instantiated. A subset of a data model 
is not the same as a data model that is "operable" to enable changes in data structure and data 
handling. Rather, the portion would simply restrict which data structures and data handling 
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would be provided. There does not appear to be a description of how the use of "portions" 
enables changes in data structure and handling without requiring programmatic changes. 
Applicant has not pointed out any portion of the specification that describes a data model that is 
operable to enable changes. 

On pages 10-11, Applicant continues the previous argument by pointing out that different 
components in the system reference different portions of the data model, and that "it should be 
obvious" that one could change a portion of the data model that hadn't been deployed without 
changing "these components." However, this argument is unclear since limitations in question 
refer to the "enterprise back end", and the "components" appear to refer to client components. 
Accordingly, this argument is not persuasive. 

Applicant concludes the previous line of arguments on page 11, essentially asserting that 
disclosure on page 37 line 19 - page 38 line 2 shows the ability to deploy new classes to a select 
group of users that "obviously would obviate the need for any programmatic changes." Here, the 
mobile data model appears to change. It is still not clear how it is "operable" to enable changes 
to data structure and data handling without programmatic changes. It does not address any 
programmatic changes that might be necessary for any "new users". While this might show that 
the mobile data model may be changed, it does not address how the adaptability of the mobile 
data model precludes the changing of the back end. 

The above arguments are not persuasive. Accordingly, these rejections are maintained. 
6. On pages 11-13, Applicant addressed the rejection of claims 17-21 under 35 U.S.C. 112, 
1 st paragraph. 
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At the bottom of page 11, Applicant suggests that claim 17 was rejected since the data 
model is not "operable". However, this limitations appears to have been addressed in regard to 
claim 1 1, not claim 17 as suggested by the Applicant (see top of page 6 of the Office action 
mailed 1 1/2/2005). Regardless, Applicant essentially argues that the data model is "operable" 
since it is used to instantiate a data store. However, the term "data model" is commonly used to 
refer to the abstract organization of data. From Wikipedia: "A data model is a model that 
describes in an abstract way how data is represented in a business organization, an information 
system or a database management system." (<http://en.wikipedia.org/wiki/Data_model>, 
accessed 8/7/2006, emphasis added). This definition appears to correspond with the use of the 
term "data model" in the originally filed specification. If a data model is an abstract definition, it 
is not clear how it could be operable. While an abstract definition of a data model might be 
useful, it is not strictly speaking, operable. Therefore, this argument, interpreted in connection 
with the rejection of claim 1 1, is not persuasive. 

On pages 12-13, Applicant essentially argues that there is full disclosure regarding "rules 
governing data handling". While it is agreed that the "conditional logic statements" as disclosed 
on page 25 lines 13-18 can be regarded as the "rules governing data handling", Applicant has not 
pointed out any description from the originally filed specification of how a change in the data 
model "effects" changes to the rules. Therefore, this argument is not persuasive and the rejection 
is maintained. 

7. On pages 14-18, Applicant argues that the rejection of claims 1-26 under 25 U.S.C. § 
103(a) is improper since there is not motivation to combine, and that Wright teaches away. 
These arguments are not convincing as addressed below. 
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On pages 14-16, Applicant essentially argues that since Wright teaches away from 
Wadhwa since Wright teaches platform independent applications development, and Wadhwa 
teaches platform dependent development. However, this analysis is misplaced for at least the 
fact that platform independent vs. platform dependent development is a systems issue, while the 
references are more concerned with the application level. Wadhwa teaches that data stored in a 
repository using an entity relationship model can be readily reused. Platform 
independence/dependency is a separate issue from data reuse. 

On pages 16-18, Applicant essentially argues that Wright already discloses the use of a 
virtual machine to permit the reuse of applications in a heterogeneous computing environment, 
and therefore would have no motivation for the reuse of data supplied through Wadhwa's data 
model. However, as addressed above, the use of a virtual machine is a systems level concept that 
does not address data model concerns. Just because an application can run on several different 
platforms, it does not preclude the need for reusable data as taught by Wadhwa. 
8. On pages 18-21, Applicant essentially argues that there is not motivation to combine 
Wadhwa with Bowman- Amuah and that Bowman- Amuah teaches away from Wadhwa. These 
arguments are not persuasive as addressed below. 

On pages 19-20, Applicant essentially argues that Bowman- Amuah does not teach a 
decoupled data model, but rather "de-coupled communication" using a "shared format". 
However, Bowman- Amuah' s decoupled communication is precisely what decouples the data 
model. The language of the claims simply call for a data model that is "decoupled from a 
particular interface", which is provided by Bowman- Amuah' s data model using de-coupled 
communication. 
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On pages 20-21, Applicant essentially argues that Bowman- Amuah teaches away from 
Wadhwa since Bowman- Amuah seeks to avoid the same problems that Wadhwa acknowledges 
as drawbacks. Applicant notes Wadhwa' s teaching against numerous system changes (Wadhwa 
column 17 lines 1-4). It appears that this is precisely the reason that one of ordinary skill in the 
art would look to Bowman- Amuah. Bowman- Amuah teaches a solution to the expressed 
problems of Wadhwa (see Bowman- Amuah column 237 lines 7-9: "In cases like this, it would be 
better to implement a communication mechanism or "shared format" that can better handle 
changes to the system."). 

9. On pages 21-25, Applicant essentially argues that Wright and Wadhwa fail to disclose, 
teach or otherwise suggest the claimed data model. These arguments are not persuasive as 
addressed below. 

On page 21-22, Applicant essentially argues that Wadhwa teaches only data relationship, 
and does not address data elements, data dependencies, and data attributes. However, it is noted 
that the claims use the alternative "one or more" to provide these limitations. As pointed out in 
the previous Office action, disclosure of one of these elements meets the language of the claim. 

On pages 22-23, Applicant essentially argues that Wadhwa uses persistent connections 
while Applicant's invention is directed to asynchronous communication. On page 23, Applicant 
essentially argues that the references do not teach "random connections, concurrently, and other 
issues that accompany the remote computing system". It is noted that these feature upon which 
applicant relies, are not recited in the rejected claims. Although the claims are interpreted in 
light of the specification, limitations from the specification are not read into the claims. See In 
re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). 
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On pages 23-24, Applicant essentially argues that Wadhwa does not disclose distribution 
attributes. However, as noted above, this limitation was provided using the alternative language 
"one or more" and was not required to meet the language of the claim. 

On pages 24-25, Applicant essentially argues that Wadhwa's data model is not "actively 
employed accessed or otherwise leveraged. . Applicant supports this argument by quoting 
Wadhwa column 7 lines 24-25: "The entity-relationship model is not the actual program". 
Applicant further suggests that Wadhwa's data model is not required or actively employed in 
interfacing applications since it is the modules that are active, and not the data model. However, 
as addressed above, a data model is an abstract definition of data. Wadhwa's modules use the 
elements defined by the data model. Such elements are required and active in interfacing 
applications. Applicant has not pointed out an enabling description of an "operable" data model. 

10. For convenience, the following objections and rejections are included in their entirety 
from the previous Office action. 

Drawings 

1 1 . The drawings are objected to under 37 CFR 1 .83(a). The drawings must show every 
feature of the invention specified in the claims. Therefore, the decoupled mobile data model 
(claims 1, 1 1, 17, 22, and 24), a mobile data model "operable to enable changes in data structure 
and data handling without requiring programmatic changes" (claim 1 1), the "changes to the 
mobile data model <that> effect changes in system data descriptions and rules governing data 
handling without requiring programmatic changes in applications included in an enterprise back- 
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end device" (claim 17), and the "mobile data model decoupled from a particular client interface 
and enterprise data source" (claim 24) must be shown or the feature(s) canceled from the 
claim(s). While the drawings show a data model (Figures 12, 13, etc.), they do not show a 
decoupled data model. In particular, claims 1,11,17, and 22 describe a mobile data model in 
terms of it being "independent". Claim 24 describes decoupling in terms of "a particular client 
interface and enterprise data source". Particularly with respect to Applicant's arguments (page 9 
paragraphs 1, 3) that Wright does not teach a decoupled mobile data model that is "defined 
explicitly and separately from client programs", such claim limitations that define the instant 
invention over the prior art should be illustrated. None of the drawings show such features of a 
mobile data model. No new matter should be entered. 

Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to 
the Office action to avoid abandonment of the application. Any amended replacement drawing 
sheet should include all of the figures appearing on the immediate prior version of the sheet, 
even if only one figure is being amended. The figure or figure number of an amended drawing 
should not be labeled as "amended." If a drawing figure is to be canceled, the appropriate figure 
must be removed from the replacement sheet, and where necessary, the remaining figures must 
be renumbered and appropriate changes made to the brief description of the several views of the 
drawings for consistency. Additional replacement sheets may be necessary to show the 
renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an 
application must be labeled in the top margin as either "Replacement Sheet" or "New Sheet" 
pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will 
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be notified and informed of any required corrective action in the next Office action. The 
objection to the drawings will not be held in abeyance. 



Claim Rejections - 35 USC § 112 

12. The following is a quotation of the first paragraph of 35 U.S.C. 1 12: 

The specification shall contain a written description of the invention, and of the manner and process of making 
and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it 
pertains, or with which it is most nearly connected, to make and use the same and shall set forth the best mode 
contemplated by the inventor of carrying out his invention. 

13. Claims 1 1-21 are rejected under 35 U.S.C. 1 12, first paragraph, as failing to comply with 
the written description requirement. The claim(s) contains subject matter which was not 
described in the specification in such a way as to reasonably convey to one skilled in the relevant 
art that the inventor(s), at the time the application was filed, had possession of the claimed 
invention. 

14. Claim 1 1 recites ". . .wherein the mobile data model is . . . operable to enable changes in 

data structure and data handling without requiring programmatic changes in the enterprise back 

end. . ." However, the originally filed specification does not provide support for these 

limitations. In contrast, page 16 line 16 - page 17 line 3 recites: 

Once a mobile data model has been built, the developer can build one or more software program 
components that will operate on the server side of the mobile computing system in order to 
integrate the mobile computing system with one or more enterprise back-end applications, at step 
416. These components, or software instances, may be built using a variety of programming 
languages, depending on the systems in question. These components may facilitate the transfer of 
data to and from enterprise systems as application requirements dictate. Each integration 
component may access application programming interfaces (APIs) provided by the mobile 
computing system in order to access a desired information instances. As application requirements 
change, the developer may enhance the integration components as needed. 

This paragraph appears to teach that a mobile data model is built before server or integration 



components can be built, and that if requirements change, the integration components may be 
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changed. If this interpretation is correct, then it would be the integration components that 

"enable changes", not the mobile data model as recited in claim 11. Further description is found 

on page 34 line 14 - page 35 line 2: 

As mentioned above, there may be three phases a developer will complete when developing a 
mobile domain solution: (1) create a mobile data model mat may allow instantiation of a domain 
data store and a mobile data store; (2) write an integration component that facilitates 
communication between a domain data store and a back-end application; and (3) write a client- 
side or mobile device bound mobile application that support interaction between a mobile data 
store and a user. In effect, the mobile data model may provide a layer of abstraction between a 
back-end database and a mobile application. As such, an integration component may access a 
domain data store instantiated from a mobile data model or a portion thereof, and a mobile 
applications may access a mobile data store instantiated from the same mobile data model or a 
portion thereof on an individual hand-held device. 

According to this passage, the mobile data model itself does not appear to be "operable" as 
recited in claim 1 1 . Rather, the mobile data model allows an instantiation in the form of a data 
store that would then interface with an integration component (item 2 above) or a mobile 
application (item 3 above). Any change in the data model would likely require a new 
instantiation of the data store, and it would seem that any change in the data store would further 
require modification to any associated integration components or applications. However, the 
specification appears to be silent in regards to the ability to change the mobile data model 
without requiring programmatic changes as recited in the claim. 

15. Claims 12-16 are rejected as being dependent upon a rejected base claim. 

16. Claim 17 contains recites ". . .changes to the mobile data model effect changes in system 
data descriptions and rules governing data handling without requiring programmatic changes in 
applications included in an enterprise back-end or mobile device." However, as addressed in the 
above rejection of claim 1 1, the specification appears to be silent on the requirements of 
programmatic changes in response to changes to the mobile data model. Further the 
specification does not expressly recite "data descriptions" or "rules governing data handling", 



Application/Control Number: 09/848,770 Page 13 

Art Unit: 2192 

and applicant has not particularly pointed out where these limitations find support in the 
originally filed specification. Reference to "Fields" used "to describe attributes" is found on 
page 29 lines 19-20. However, these field descriptions used in the data model do not appear to 
affect any such "system data descriptions". Further, while the specification refers to "rules in the 
system dictate" (page 13 lines 19-21, and page 13 lines 1-4), reference to "rules governing data 
handling", as recited in the claim, was not found in the specification. Page 24 line 7 also refers 
to a "rules-processing engine". This engine appears to respond to transactions, but the 
specification does not mention any change in the rules engine in direct response to a change in 
the mobile data model. 

1 7. Claims 1 8-21 are rejected as being dependent upon a rejected base claim. 

18. The following is a quotation of the second paragraph of 35 U.S.C. 1 12: 

The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the 
subject matter which the applicant regards as his invention. 

19. Claims 1 1-21 are rejected under 35 U.S.C. 1 12, second paragraph, as failing to set forth 
the subject matter which Applicants regard as their invention. Evidence that claims 11-21 fail to 
correspond in scope with that which Applicants regard as the invention can be found in the reply 
filed 9/15/05. On page 10, paragraph 1 of the response, Applicant argues that the present 
invention allows alterations to be made "without significant supplementary programming". 
However, claim 1 1 recites "without requiring programmatic changes in the enterprise back end". 
These two statements appear to conflict. The phrase "without significant supplementary 
programming" implies that some amount of supplementary programming is required, but the 
claim language says that no supplementary programming is required. In light of Applicant's 
comments, it is not clear if any supplementary programming would or would not be required, 
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and the originally filed specification does not appear to address the issue. Claim 17 contains 
language similar to claim 11, and is rejected for the same reasons. Claims 12-16 and 18-21 are 
rejected as being dependent upon a rejected base claim. 

Claim Rejections - 35 USC §103 

20. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

21. Claims 1-26 are rejected under 35 U.S.C. 103(a) as being unpatentable over prior art of 
record U.S. Patent 5,857,201 to Wright et al. (hereinafter referred to as "Wright") in view of U.S. 
Patent 5,295,222 to Wadhwa et al. (hereinafter "Wadhwa") in view of U.S. Patent 6,332,163 to 
Bowman- Amuah (hereinafter "Bowman-Amuah"). 

As per claim 1, Wright discloses: 

A method for use of a software application (column 13 line 1 - column 14 line 
15), the method comprising: 

creating a mobile data model the mobile data model ... required by a mobile 

application See column 5 lines 49-52: 

The FL Engine 160 incorporates a full local database implementation that allows data to 
be manipulated and collected by the FL client while not connected to the FL server 132. 

instantiating at least a portion of the mobile data model to create a mobile data 
store containing enterprise information column 2 lines 24-26: 
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The client/server (C/S) architecture of the present invention is designed to allow the 
client to become a direct extension of the corporate data sources. 

also column 2 lines 50-58: 

. . .in a computer network, including a server, a data source, and a mobile client having a 
database, a method of synchronizing the client database and data source during a non- 
persistent connection, the method comprising the steps of connecting the mobile client to 
the server; manipulating the client database by the server; updating the data source 
responsive to the manipulation by the server; and disconnecting the client from the 
server. 

creating one or more mobile software applications to interact with the mobile 
data store column 2 lines 34-38: 

Applications built with existing development tools can be enabled to either exchange 
data on demand, or provide facilities for a multi-port server allowing remote database 
access and e-mail access from the field. 

making the mobile software application and at least a portion of the mobile data 
model available to a consumer In Wright, a consumer can be considered a PDA, which 
functions as the client in the client/server architecture disclosed. As such, the application 
and data model are inherent to the function of the system, since without availability to 
them, the system loses its primary functionality. 

Wright also does not expressly disclose a data model explicitly describing one or 
more data elements, data relationships, data dependencies and data distribution 
attributes wherein the mobile data model is an independent entity... However, in an 
analogous environment, Wadhwa teaches that an independent data model that defines at 
least data relationships can be used for generation and distribution of applications. See 
column 6 lines 59-63: 



An association between entities is known as a relationship. For example in FIG. 3 the 
entity, Organization 1, is now linked to the entity, Employee, by the relationship, 
Employs 3. Relationships are also defined by attributes. 
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Applicant's use of alternative language in the claim, i.e. "one or more" allows Wadhwa 

to teach this claim limitation with the above cited data relationship attributes. It would 

have been obvious to one of ordinary skill in the art at the time the invention was made to 

use Wadhwa's data model including data relationship attributes with Wright's software 

platform. One of ordinary skill would have been motivated to provide a data model that 

can be readily re-used in subsequent applications (Wadhwa column 7 lines 16-18). 

Wright does not expressly disclose wherein the mobile data model is ...decoupled 

from a particular interface and enterprise data source. However, in an analogous 

environment, Bowman- Amuah teaches that it is important to decouple a data model. See 

Bowman- Amuah column 236 lines 51-56 

Many additional factors influence the detailed design of this communication mechanism. 
Some systems support volatile and constantly changing object models, data models and 
data structures. In these systems, flexible, de-coupled communication is extremely 
important. 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to use Bowman-Amuah's teaching of a decoupled data model with Wadhwa's 
independent data model. One of ordinary skill would have been motivated to use a 
shared format that decouples the model in order to efficiently handle changes to the 
system (Bowman-Amuah column 237 lines 7-9). 

As per claim 2, the above rejection of claim 1 is incorporated. Wright further 
discloses: wherein the consumer comprises a distributed computing device (column 2 
lines 38-42). 
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As per claim 3, the above rejection of claim 1 is incorporated. Wright further 
discloses: initiating deployment of the mobile software application and the at least a 
portion of the mobile data model to a plurality of distributed computing devices (column 
2 lines 32-34). 

As per claim 4, the above rejection of claim 1 is incorporated. Wright further 
discloses: using the mobile data model to create a domain data store in a middle tier 
server (column 2 lines 56-57). 

As per claim 5, the above rejection of claim 1 is incorporated. Wright further 
discloses: wherein a first consumer receiving the mobile software application can access 
and update data instances in the domain data store using the at least a portion of the 
mobile data model (column 4 lines 38-49). 

As per claim 6, the above rejection of claim 1 is incorporated. Wright further 
discloses: wirelessly deploying the mobile software application to a first consumer 
(column 5 lines 40-41; also column 4 lines 2-4; also column 1 1 lines 16-17). 

As per claim 7, the above rejection of claim 1 is incorporated. Wright further 
discloses: developing a distribution rule that identifies a group of consumers; and 
initiating deployment of the mobile software application to the group of consumers 
(column 11 lines 10-17). 
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As per claim 8, the above rejection of claim 1 is incorporated. All further 
limitations have been addressed in the above rejections of claims 3, 4, and 5. 

As per claim 9, the above rejection of claim 1 is incorporated. All further 
limitations have been addressed in the above rejections of claims 2, 3, and 6. 

As per claim 10, the above rejection of claim 9 is incorporated. Wright further 
discloses: wherein the first consumer comprises a group of mobile workers sharing a job 
description (column 4 lines 17-21). 

As per claim 11, Wright discloses: 

A system for application development in a mobile domain (Figure 2), comprising: 
a middle tier server; a domain data store maintained in the middle tier server, the 

domain data store representing enterprise information maintained in an enterprise back 

end column 6 lines 27-33: 

The FormLogic Server 132 serves as a "gateway" between FormLogic Clients (e.g., 136, 
142, 146) and enterprise data sources (e.g., 180, 182). The server 132 supports what is 
known as a multi-tier client/server model in that it creates an intermediate server 
between the client and the "traditional" or "original" server. 

also column 7 lines 45-64: 

A service defines the relationship between a client application and an enterprise data 
source. Examples of services include Mail, World Wide Web Gateway, or Inventory... 
The service instantiations can be considered as interfaces between the "master" service 
and the connection. 
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Here, the service instantiations represent enterprise information maintained in an 
enterprise back end, and as such can be interpreted as domain data stores within the 
middle tier server.); 

an application development engine operable to generate instructions that can be 
deployed to the distributed computing platform and that allow the distributed computing 
platform to access information within the mobile data store column 4 lines 2-4: 

Complete Software Distribution interface allowing developers to programmatically install 
FormLogic forms, agents and tables during connections"; also column 4 lines 41-43: 
"This allows portions of databases to be carried into the field where they can be modified 
and later synchronized with the server database."; also column 5 lines 16-17: "The FL 
client 136 includes an FL Engine 160 which allows FormLogic applications to execute 
on a variety of handheld devices"). 

Wright does not expressly disclose a mobile data model ... operable to enable 

changes in data structure and data handling without requiring programmatic changes in 

the enterprise back end However, in an analogous environment, Bowman- Amuah 

teaches that a streamed model can be described using meta-data. See Bowman- Amuah 

column 237 lines 7-13: 

In cases like this, it would be better to implement a communication mechanism or 
"shared format" that can better handle changes to the systems. 

Therefore, use a Self-Describing Stream and create a stream that contains message data 
AND descriptive meta-data. Then use a message language to read the formatting 
information and meta-data off of the stream 

This "Self-Describing Stream" enables changes to a system without requiring 
programmatic changes since the stream provides all the details regarding its contents 
through descriptive meta-data. It would have been obvious to one of ordinary skill in the 
art at the time the invention was made to use Bowman- Amuah' s teaching of a self- 
describing stream with Wadhwa's independent data model. One of ordinary skill would 
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have been motivated to use a shared format that permits the efficient handling of changes 
to the system (Bowman- Amuah column 237 lines 7-9). 

All further limitations have been addressed in the above rejection of claim 1. 

As per claim 12, the above rejection of claim 1 1 is incorporated. Wright further 
discloses: wherein the application development engine is operable to generate object 
oriented instructions (column 5 lines 33-36, referencing U.S. Pat. 5,704,029 [incorrectly 
listed as 5,204,029], shows inherent use of the Newton Script object-oriented language.). 

As per claim 13, the above rejection of claim 1 1 is incorporated. Wright further 
discloses: further comprising a graphical user interface (GUI) engine responsive to the 
application development engine (column 5 lines 30-33). 

As per claim 14, the above rejection of claim 1 1 is incorporated. Wright further 
discloses: a mobile data modeler operable to access the mobile data model (column 5 
lines 33-36: "script engine"); and 

a graphical user interface (GUI) engine operable to present a developer with an 
interface for the mobile data modeler to modify the mobile data model (column 5 lines 
33-36: "user interface"). 
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As per claim 15, the above rejection of claim 1 1 is incorporated. Wright further 
discloses: further comprising an enterprise back end system maintaining the enterprise 
information (column 4 lines 65-67). 

As per claim 16, the above rejection of claim 1 1 is incorporated. All further 
limitations have been addressed in the above rejection of claim 6. 

As per claim 17, Wright discloses: 

a memory associated with the distributed computing platform, the memory storing 
a mobile data store comprising information indicative of information in an enterprise 
backend (column 5 lines 18-20: The Apple MessagePad Model 120 inherently comprises 
memory). 

All further limitations have been addressed in the above rejections of claims 1 and 

11. 

As per claim 18, the above rejection of claim 17 is incorporated. All further 
limitations have been addressed in the above rejection of claim 1. 

As per claim 19, the above rejection of claim 18 is incorporated. Wright further 
discloses: wherein the mobile application comprises user task specific routines (column 6 
lines 46-59). 
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As per claim 20, the above rejection of claim 18 is incorporated. Wright further 
discloses: wherein the mobile application comprises user specific routines (column 7 
lines 45-53). 

As per claim 21, the above rejection of claim 20 is incorporated. Wright further 
discloses: wherein the user specific routines are specific to a first user of the distributed 
computing platform, the system further comprising: a second mobile application that 
comprises a second set of specific routines for a second user of the distributed computing 
platform (column 10 line 66 - column 12 line 19). 

As per claim 22, Wright discloses: 

establishing a first communication link with a mobile computing device; 
disconnecting the first communication link; establishing a second communication link 
with the mobile computing device; and receiving transaction data across the second 
communication link, the transaction data resulting from execution of the client-side 
application by the mobile computing device at least a portion of the execution occurring 
after disconnecting the first communication link and before establishing the second 
communication link column 5 lines 52-58: 

Upon connection, this local database 172 is automatically 
manipulated by the FL server 132. The FL server 132 can 
query the client database 172, add data to the client 
database, or remove data from the client database in order 
make updates to both the client and server databases to 
reflect changes that have happened on both sides since the 
last connection. 
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Wright does not expressly disclose the mobile data model ... capable of 

independently describing key details required by a client-side application; However, in 

an analogous environment, Bowman- Amuah teaches that a streamed model can be 

described using meta-data. See Bowman- Amuah column 237 lines 7-13: 

In cases like this, it would be better to implement a communication mechanism or 
"shared format" that can better handle changes to the systems. 

Therefore, use a Self-Describing Stream and create a stream that contains message data 
AND descriptive meta-data. Then use a message language to read the formatting 
information and meta-data off of the stream 

This "Self-Describing Stream" enables changes to a system without requiring 
programmatic changes since the stream provides all the details regarding its contents 
through descriptive meta-data. It would have been obvious to one of ordinary skill in the 
art at the time the invention was made to use Bowman- Amuah' s teaching of a self- 
describing stream with Wadhwa's independent data model. One of ordinary skill would 
have been motivated to use a shared format that permits the efficient handling of changes 
to the system (Bowman- Amuah column 237 lines 7-9). 

All further limitations have been addressed in the above rejection of claim 1. 

As per claim 23, the above rejection of claim 22 is incorporated. Wright further 
discloses: deriving a first mobile data model from an enterprise information system; and 
modifying the first mobile data model to yield the deployable mobile data model (column 
4 lines 38-43). 

As per claim 24, Wright discloses: 
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A method for application development and deployment (column 6 lines 34-38: 

The FL Builder (not shown) is a development tool, previously described in applicant's 
copending patent application, now U.S. Pat. No. 5,704,029, used to build FormLogic 
applications that can be executed on a variety of hardware platforms. 

adding at least a portion of the mobile data model to a package Developing a 

mobile data model is inherent to adding it to a package, otherwise there would be nothing 

to add; see column 6 lines 63-64: 

Communications agents, also just known as "agents", are developed to describe the, 
communications "session". Communications agents know how to connect to a particular 
host, perform a set of operations or tasks, which usually includes synchronizing the 
host data source, e.g., 180, with the client database 172, and then disconnecting. The 
idea is that a developer can create a communications agent that represents each of the 
communications sessions that a field user may need. 

Here, the mobile data model is evidenced by the set of operations that make up an agent. 
An agent here is considered to be equivalent to a package. In order for the agent to 
operate on the host data source, it must inherently use a data model, otherwise it would 
not be able to find or distinguish the data contained therein. 

including the package in a mobile user application column 7 lines 21-23: 

An exemplary Sessionl 200 called Daily Connect includes three tasks: Taskl 204, e.g., 
GetMail; Task2 206, e.g., SendMail; and Task3 208, e.g., Updatelnventory. 

deploying the mobile user application to a distributed computing device See 
column 4 lines 2-4 as cited above in the rejection of claim 1 1. 

All further limitations have been addressed in the above rejection of claim 1. 



As per claim 25, the above rejection of claim 24 is incorporated. Wright further 
discloses: including at least an integration portion of the mobile data model in an 
application comprising an integration component (column 6 lines 49-56; An integration 
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component in inherent to a the "retrieve work order" session described in this passage. 
Without an integration component, a new work order would not be able to be examined.). 

As per claim 26, the above rejection of claim 24 is incorporated. Wright further 
discloses: wherein the mobile user application is operable to colonize the distributed 
computing device and initiate the instantiation of a data store on the distributed 
computing device, the instantiation described by the at least a portion of the mobile data 
model added to the package (column 4 lines 38-43). 

Conclusion 

22. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to J. Derek Rutten whose telephone number is (571)272-3703. The 
examiner can normally be reached on T-F 6:00-4:30. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Tuan Q. Dam can be reached on (571)272-3695. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 
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